NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/16184

Internet Message Format | 1996-08-05 | 3.1 KB

Path: news.cais.com!news
From: Eric Vought <[e-mail]>
Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
Subject: Re: What Should An Exception Handling Do? -- Clarification of rules
Date: Tue, 09 Apr 1996 17:31:49 -0400
Organization: Capital Area Internet Service [e-mail] 703-448-4470
Message-ID: <[e-mail]>
References: <[e-mail]> <4ke1kp$[e-mail]>
NNTP-Posting-Host: ip226.idsonline.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.2.13 i586)

> Real world case in point. Imagine a fictious object runtime which must
> have one binary support the range of operating systems with the interface
> identified as Win32. Under Win32s many file operations will return an
> error code 87 when in fact Windows95 or Window NT will give a notification
> code with more meaning. on the Win32s platform an error code 87 may
> indicate a dire consequence or merely be an informative notification.
> Structuring the File System framework to use exception handlers can allow
> an 87 error code to raise an exception and let the arbitrator determine
> the settlement of the outcome. That is to say, is this a trivial
> notification? Or, is this a serious error condition. In the first case, we
> may resume. In the second, we must take direct alternative action.

This is a perfect example of what I see as a bad use of exceptions. When
the filesystem code recieves an error code 87, it should *not* throw an
exception. Instead, it should try to determine the nature of the error
*within* the method and then throw a more appropriate exception in a
serious case. The problem is that throwing and processing an error in
order to determine that, in fact, the situation is not dire takes just
as long as processing a real error. Since, presumably, non-dire errors
occur more often than dire errors, you are wasting a significant amount
of processing power to throw and catch these exceptions. Additionally,
you are violating encapsulation by allowing the error handling routine
to affect the execution path of the method. This means that the caller
must *know* how to affect the method's internal state, and therefore
must know implementation details of the method. BAD.

The better way to do it is to have the public method call private
methods which will terminate on errors (either by returning a signal
value or throwing an exception). The public code then decides whether
the condition is an error and either retries or resumes operation by
calling further private methods or throws an exception from there.

Remember that the primary reason for exceptions is to support OOP and
data encapsulation. In other words, for informing a client that
something has occurred and allowing them to deal with it *without*
revealing internal details. Within implementation code (which seems to
be what resumption most directly supports), where one knows how the
condition will be handled, return values and branch statements are more
efficient, often simpler, and more elegant.